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PROPOSED MORATORIUM ON CHANGES TO NETWORK PROTOCOL 


Bill Crowther’s RFC No. 67 raised a much more fundamental issue 
than the question of marking. Any change to presently established 
protocol is going to involve changes in the hardware/software 
development efforts that have, in some instances, been going on for 
over 6 months. In the case of Multics, this effort has yielded 
programs either complete or in the advanced debugging stages. This 


is no doubt true for many other sites as well. 


The arguments being developed here are not that the present 
protocol is ideal, but rather that everyone has agreed that it is 
workable and has begun implementation of it. We would therefore like 
to propose a moratorium on most changes to this protocol for the next 
6 months, or however long it takes to get this system running and to 


observe its characteristics. 


Specifically this means not making changes that only effect the 
efficiency or ease of implementation. If a major design problem is 
uncovered it should still be brought forward for consideration, as 
could issues that represent extensions to the existing system. But, 


changes to the details of the present system should not be made. 


There are several points to be made in favor of this argument. 


[Page 1] 


Network Working Group RFC 72 Robert D. Bressler 


The first, and perhaps the most important, is getting the system 


working as soon as possible. The major benefits of the network will 
be in the uses to which it is put, and development along those lines 
cannot really get off its feet until the network is operational. We 
feel that, although the effort needed to reprogram part of the NCP at 
a later date will undoubtedly be greater, it will be hidden by the 
parallel effort then going on involving network usage and higher 


level network development. 


Another problem that immediately arises is what should constitute 
an official change to the protocol. The history of the development 
of the current protocol shows that once an idea is raised, it is 
modified many times before it is generally agreeable to all. Thus 
each new suggestion for change could conceivably retard program 


development in terms of months. 


Finally there is the consideration that an idea may prove 
unfeasible once actual operation of the network begins. Any one of 
the currently agreed upon issues may be reopened when full scale 


testing begins to take place. 


We think that these considerations are important enough to freeze 
the network protocol unless any problems arise that would make a 
certain feature unimplementable. Changes then leading simply to 
greater efficiency would be saved until actual network operation has 


been tested. 
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This is not to say that new ideas or arguments should not be 
brought forward, but that they should be brought forward with the 
understanding that they are not to be considered for immediate 


implementation but rather to be discussed with a view toward possible 


later implementation. This concept might be reflected by titling 


such documents, "Proposal for Post-Moratorium Changes to ..." 


[ This RFC was put into machine readable form for entry ] 
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